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Abstract 


This document specifies Protocol for carrying Authentication for 
Network Access (PANA) Relay Element functionality, which enables PANA 
messaging between a PANA Client (PaC) and a PANA Authentication Agent 
(PAA) where the two nodes cannot reach each other by means of regular 
IP routing. 


Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6345. 
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Copyright Notice 


Copyright (c) 2011 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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1. Introduction 


Protocol for carrying Authentication for Network Access (PANA) 
[RFC5191] is a UDP-based protocol to perform Extensible 
Authentication Protocol (EAP) authentication between a PANA Client 
(PaC) and a PANA Authentication Agent (PAA). 


This document specifies PANA Relay Element (PRE) functionality, which 
enables PANA messaging between a PaC and a PAA where the two nodes 
cannot reach each other by means of regular IP routing. For example, 
in ZigBee IP [ZIGBEEIP] that uses 6LOWPAN [RFC4944], a joining node 
(PaC) can only use a link-local IPv6 address to communicate with a 
parent node prior to PANA authentication. The PAA typically resides 
in a 6LOwPAN Border Router (6LBR) [6LOWPAN-ND], which is often 
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multiple IP hops away from the PaC. The PRE implemented on the 
parent node is used for relaying PANA messages between the PaC and 
the PAA in this scenario. 


1.1. Specification of Requirements 


In this document, several words are used to signify the requirements 
of the specification. These words are capitalized. The key words 
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 
are to be interpreted as described in [RFC2119]. 


2. PANA Relay Element 


A PANA Relay Element (PRE) is a node that is located between a Pac 
and a PAA. It is responsible for relaying the PANA messages between 
the PaC and the PAA. The PRE does not need to maintain per-PaC 
state. From the PaC’s perspective, the PRE appears as the PAA. 
Normal IP routing is performed between the PRE and the PAA. A PAA 
can communicate with multiple PREs. A PRE can communicate with 
multiple PAAs, and it will choose one PAA to communicate with for a 
given PaC. By default, the PaC discovers the PRE using the normal 
mechanism for PAA discovery as defined in [RFC5192]. PRES are 
assumed to be configured with the IP address(es) of the PAA(s). 
Dynamic PAA discovery schemes for PRES are outside the scope of this 
document. 


The PRE and the PAA support the relay operation as follows. 


When the PRE receives a PANA message from the PaC, it creates a PANA- 
Relay (PRY) message (see Section 4.1) containing a Relayed-Message 
AVP (see Section 5.2) and a PaC-Information AVP (see Section 5.1). 
The Relayed-Message AVP encapsulates the entire PANA Message received 
from the PaC. The PaC-Information AVP contains the PaC’s IP address 
and UDP port number used for sending the PANA messages. The PRY 
message is sent to the PAA. 


When the PAA receives the PRY message, it retrieves the Pac- 
originated PANA message from the Relayed-Message AVP and the PaC’s IP 
address and UDP port number from the PaC-Information AVP. The Pac- 
originated PANA message is processed in the same way as specified in 
[RFC5191], with the following exceptions: 


(a) The IP address and the port number contained in the Pac- 
Information AVP and the source IP address and UDP port number of 
the PRE are used to identify the PaC among multiple PANA-Client-— 
Initiation messages sent from different PaCs through the same PRE 
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or sent from more than one PaC with the same the IP address and 
the port number through different PREs. 


(b) The IP address and the port number contained in the Pac- 
Information AVP are maintained by the PAA in the PANA session 
attribute "IP address and UDP port number of the Pac" [RFC5191]. 


(c) The IP address and UDP port number of the PRE are maintained by 
the PAA in a new PANA session attribute "IP address and UDP port 
number of the PRE". A PANA session is referred to as a relayed 
PANA session if this attribute has a non-null value. 


When the PAA originates a PANA message for a relayed PANA session, it 
sends a PRY message to the PRE’s IP address and sets the destination 
UDP port number to the UDP port number of the PRE maintained in the 
PANA session attribute "IP address and UDP port number of the PRE". 
The PRY message includes a Relayed-Message AVP containing the PAA- 
originated PANA message and also includes a PaC-Information AVP 
containing the PaC’s IP address and UDP port number. 


When the PRE receives the PRY message, it retrieves the PAA- 
originated PANA message from the Relayed-Message AVP and the PaC’s IP 
address and UDP port number from and PaC-Information AVPs. The PAA- 
originated PANA message is sent to the PaC’s IP address with the 
source UDP port number set to the PANA port number (716) and the 
destination UDP port number set to the UDP port number contained in 
the Relayed-Message AVP. 


The Session Identifier and Sequence Number of any PRY message are set 
to zero. PRY messages are never retransmitted by the PRE or the PAA. 
Note that the PANA message carried in a Relayed-Message AVP may be 
retransmitted by the PaC or PAA, leading to transmission of a new PRY 
message carrying the same Relayed-Message AVP. 


A PAA that supports this specification MUST be able to process PRY 
messages for PaC-initiated PANA sessions. 


This specification assumes there is at most one PRE between the Pac 
and the PAA. Performing relay operation on a PANA message that is 
already relayed (i.e., carried inside a PRY message) is out of scope 
of this specification. 


Figure 1 is an example message flow with a PRE. 
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Pac PRE PAA srcIP:port->dstIP:port 
ie e SO apipi. => IP2a:716 
2. —-—--PRY[P{IP1:p1},R{PCI}]--> IP2b:p2 -> IP3:716 
3. <--PRY[P{IP1:p1},R{PAR}]--- IP3:716 -> IP2b:p2 
4. <--PAR--—- TP2a:716 -> IP1:p1 
Dis -—--PAN--> IP1:p1 -> IP2a:716 
Or ---PRY[P{IP1:pl},R{PAN}]--> IP2b:p2 -> IP3:716 
Aks <--PRY[P{IP1:p1},R{PAR}]--- IP3:716 => IP2b:p2 
8. <--PAR--- TP2a:716 -> IP1:p1 
9. —--PAN--> IP1:p1 -> IP2a:716 

10. ---PRY[P{IP1:pl1},R{PAN}]--> IP2b:p2 -> IP3:716 


IP1 is the IP address of Pac. 


IP2a and IP2b are the IP addresses of PRE. 
IP2a is used for communicating with Pac. 
IP2b is used for communicating with PAA. 
The two IP address may be the same. 


IP3 is the IP address of PAA. 


pl is PaC-assigned UDP port number. 
p2 is PRE-assigned UDP port number. 


P: PaC-Information AVP 
R: Relayed-Message AVP 


Figure 1: Example Call Message for PANA Relay 
3. Security of Messages Sent between PRE and PAA 


PRE/PAA security is OPTIONAL since PANA messages are designed to be 
used in untrusted networks, but if a cryptographic mechanism is 
supported, it SHOULD be IPsec. When the device characteristics 
preclude support for IPsec, an alternative mechanism such as DTLS 
[RFC4347], or link-layer cryptographic security, etc., may be used 
instead. This section describes how IPsec [RFC4301] can be used for 
securing the PANA relay messages. 
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When IPsec is used, each PRE must have an established pairwise trust 
relationship with a PAA. That is, if messages from a PaC will be 
relayed by a PRE to a PAA, the PRE and PAA must be configured to use 
IPsec for the messages they exchange. 


PRES and PAAs that support secure PRE to PAA communication use IPsec 
under the following conditions: 


Selectors 


Mode 


Key management 


Security policy 


Authentication 


Availability 
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PRES are manually configured with the addresses of 
the PAAs to which PANA messages are to be forwarded. 
PAAs that will be using IPsec for securing PANA 
messages must also be configured with a list of the 
PRES to which messages will be returned. The 
selectors for the PREs and PAAs will be the pairs of 
addresses defining PRES and PAAs that exchange PANA 
messages on the PANA UDP port 716 in their source or 
destination port. 


PRES and PAAS use transport mode and ESP. The 
information in PANA messages is not generally 
considered confidential, so encryption need not be 
used (i.e., NULL encryption can be used). 


Because the PRES and PAA must be manually 
configured, manually configured key management may 
suffice, but does not provide defense against 
replayed messages. Accordingly, IKE with preshared 
secrets SHOULD be supported. IKE with public keys 
MAY be supported. 


PANA messages between PREs and PAAs should only be 
accepted from PANA peers as identified in the local 
configuration. 


Shared keys, indexed to the source IP address of the 
received PANA message, are adequate in this 
application. 


Appropriate IPsec implementations are likely to be 
available for PAAs and for PRES in more featureful 
devices used in enterprise and core ISP networks. 
IPsec is less likely to be available for PREs in 
low-end devices primarily used in the home or small 
office markets. 
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4. PANA Messages for Relay Operation 
4.1. PANA-Relay 


The PANA-Relay (PRY) message is sent by the PRE to the PAA or by the 
PAA to the PRE. It contains one PaC-Information AVP and one Relayed- 
Message AVP. The PRY message SHOULD NOT carry other AVPs. 


In a PRE-originated PRY message, the PaC-Information AVP contains an 
IP address and the UDP port number of the PANA message that was 
originated by the PaC and is contained in the Relayed-Message AVP. 


In a PAA-originated PRY message, the information in the Pac- 
Information AVP MUST be copied from the "IP address and UDP port 
number of the PaC" attribute of the associated PANA session 
[RFC5191]. 


The Session Identifier and Sequence Number field of any PRY message 
MUST be set to zero. A PRY message MUST NOT be retransmitted by the 
PRE or the PAA. 
PANA-Relay ::= < PANA-Header: 5 > 
{ PaC-Information } 
{ Relayed-Message } 
*[ AVP ] 


5. PANA AVPs for Relay Operation 

5.1. PaC-Information AVP 
The PaC-Information AVP (AVP Code 10) is of type OctetString and 
contains an IP address (16-octet for an IPv6 address or 4-octet for 
an IPv4 address) followed by a 2-octet UDP port number of the Pac, 


both encoded in network-byte order. 


5.2. Relayed-Message AVP 


The Relayed-Message (AVP Code 11) is of type OctetString and contains 
a relayed PANA message excluding the UDP and IP headers. 
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6. Security Considerations 


A PRE’s main objective is to assist transport of PANA messages 
between the PaC and the PAA. Relay operation performed between the 
PRE and the PAA forms an additional logical link for relaying the 
end-to-end PANA messages between the PaC and the PAA. In that sense, 
a PRE resembles a bridge or a router that sits between the PaC and 
the PAA when non-relayed PANA [RFC5191] is used. 


A PRE can pose certain threats to the relayed PANA messages. A PRE 
can delay or drop PANA messages sent by the PaC or the PAA. It can 
also spoof or modify PANA messages sent towards the PaC or the PAA. 
These threats are similar to what an on-path bridge/router (i.e., a 
man-in-the-middle, MitM) can pose to non-relayed PANA. EAP and PANA 
protocols are designed to operate over unsecure links where 
aforementioned threats can already exist. Even though these threats 
cannot be leveraged to gain unauthorized network access, or 
compromise of cryptographic keys (e.g., MK, MSK, EMSK, etc.), other 
damages such as preventing authentication to complete, or denial-of 
service are still possible. 


Even though the PRE-to-PAA relay path appears to be a separate 
additional logical link for transporting the PANA messages, the PRE 
may pose a few additional risks versus traditional on-path bridges 
and routers. The following explains the risks and mitigations of PRE 
as a relay device. 


The PRE inserts PaC-Information AVP as the PaC-generated PANA packet 
is encapsulated in a PRY packet to the PAA. This AVP carries the IP 
address and the UDP port number values of the PANA packet as sent by 
the PAC. These values are already carried inside the IP and UDP 
headers with non-relayed PANA and they are not necessarily secured. 
EAP and PANA are designed to work in the absence of their protection. 
Therefore, no additional PANA-layer security is needed when these 
values are carried as PANA AVPs between the PRE and the PAA. Ifa 
future document defines additional payload AVPs for the PRY messages, 
there may be a need to define additional security for those messages. 


A rogue PRE can spoof PANA messages on behalf of a victim PaC and 
receive the PAA response irrespective of the location of the PRE with 
respect to the network topology. Achieving the same threat with non- 
relayed PANA requires the rogue node be an MitM, otherwise the 
spoofed packets may be dropped by the ingress filtering network 
elements, or the responses would be directly sent to the victim Pac 
IP address and may not be received by the rogue node. Nevertheless, 
such a rogue PRE cannot perform full initial authentication on behalf 
of the victim PaC unless it also holds the PaC’s credentials 
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(including the master key). Furthermore, any spoofed PANA messages 
after the initial authentication will fail the integrity checks at 
the PAA when a key-generating EAP method is used. 


The only state that can change on the PAA upon a rogue PRE sending a 
spoofed PRY is the IP address and UDP port number of the PRE stored 
as PANA session attributes, which impacts where the PAA sends the 
next PANA packet (i.e., to the rogue PRE instead of the legitimate 
PRE). The PAA also needs to handle the PaC-Information AVP in 
addition to the PaC-originated PANA message carried in the Relayed- 
Message AVP, so use of the PRE may impose additional storage 
requirements on the PAA. A rogue PRE generating a valid PANA packet 
requires it be a MitM in order to synch up with the PANA session 
state and attributes on the PaC. Such a MitM can already disturb the 
EAP and PANA even without playing the role of a PRE. 


An unauthorized node pretending as PAA can spoof the relayed PANA 
messages to the PRE in order to get them delivered to the Pac. While 
the harm caused by such spoofed packets are limited (due to the EAP 
and PANA design with unsecured network operation in mind), the 
processing of bogus packets can cause processing load on the Pac. 


Some of the risks stemming from the aforementioned threats are 
already handled by the EAP and PANA as described. The residual risks 
shall be mitigated using additional physical or cryptographic 
security in the network hosting the PREs and the PAAs. Access 
control lists implemented on the PRE, PAA, or intermediary firewalls 
supported by cryptographic or physical authentication/authorization 
are needed for protecting legitimate PRE and PAAs against rogue ones. 
Details of the cryptographic mechanisms using IPsec are specified in 
Section 3. Use of manually configured preshared keys for IPsec 
between PRES and PAAs does not defend against replayed PANA messages. 


PREs do not need to maintain per-PaC state; therefore, they are 
robust against resource consumption DoS (Denial-of-Service) attacks. 


In the relay operation, the IP address of the PAA that is seen by the 
PaC (i.e., an IP address of the PRE) is different from the IP address 
of the PAA that is seen by the authentication server. If an EAP 
channel binding solution uses the IP address of the PAA as part of 
channel binding parameters, such a solution must take this into 
account. Note that the same issue arises even when non-relayed PANA 
is used and the PAA has one IP address configured on its interface 
facing the PaC and another IP address on the other interface facing 
the authentication server. 
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7. 


9. 


9. 


IANA Considerations 
As described in Sections 4 and 5, and following the new IANA 
allocation policy on PANA messages [RFC5872], one Message Type and 
two PANA AVP Codes have been assigned. 


o A Message Type of 5 for PANA-Relay (PRY) message with the ’R’ 
(Request) bit cleared. 


o A standard AVP Code of 10 for PaC-Information AVP. 

o A standard AVP Code of 11 for Relayed-Message AVP. 
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